Fork-local infrastructure. Never intended for upstream. Everything here lives under notify-bench/ and would not be proposed to -hackers in this form. The upstream-bound patch is the documentation change in #83, which this PR supplies the supporting measurements for; background and analysis are in #82.

Why it exists

The obvious experiment — compare INSERT against INSERT; NOTIFY — does not isolate the lock. It measures the lock plus the SLRU queue insert, the utility statement itself, and an extra client round trip. Any speedup it shows is unattributable.

notify-bench/instrumentation/0001-MEASUREMENT-ONLY-skip-notify-commit-lock.patch fixes that. It makes the identical binary skip only the LockSharedObject() call in PreCommit_Notify() when PG_NOTIFY_NOLOCK is set in the postmaster environment. Both arms run the same executable, the same SQL, the same number of round trips, and insert the same queue entries; they differ by that one call.

The skip is semantically unsafe — it breaks the commit-order guarantee that the lock exists to provide. It is a measurement device, not a proposed optimization, and the patch is named accordingly.

Headline result

synchronous_commit=on, zero listeners, 3 reps, median [min-max] TPS:

The gap recovered column is the point. If NotifyQueueLock — the SLRU queue lock — simply became the next bottleneck once the heavyweight lock was gone, removing the heavyweight lock would buy little. It does not: through 16 clients the no-lock arm reaches the NOTIFY-free control, and at 64 clients the residual is only ~26% of the gap. The commit-time lock, not the queue, is what bounds notifying throughput here.

The hardware-independent framing

Absolute TPS on a 4-vCPU box is not interesting. The wait-event data is, because it holds regardless of how fast the disk is: both arms run with exactly one fsync in flight at all times. The difference is what is queued behind it. The control arm has ~21 backends waiting on that one flush and group-committing with it; the NOTIFY arm has zero, because those backends are stuck a step earlier, waiting for the object lock and not yet in the commit path at all.

Group-commit batch factor ~21 versus exactly 1. That ratio is a property of the serialization, not of this storage.

Known defects — documented, not hidden

notify-bench/README.md enumerates these. The most important one invalidates a result:

• The psql -f <fifo> listeners never call PQconsumeInput. They jam in ClientWrite instead of draining the queue. scripts/checkjam.sh demonstrates it directly: 50 of 50 listeners wedged. This flatters master and punishes v18 — that is, the bias runs in favour of the conclusion the harness was built to test, which is the worst direction for it to run. The "interested listener" results are therefore retracted. The uninterested-listener results, including the table above, do not depend on listener draining and are unaffected.

Also, in decreasing order of severity:

• Single samples everywhere outside ab_lock.csv — no repetition, no dispersion.
• The synchronous_commit=off rows sit at roughly a 50% noise floor; differences there are not meaningful.
• A 4-vCPU box with pgbench and the listener processes co-resident with the server, so the load generator competes with what it measures.
• No latency percentiles recorded, only throughput.
• No synchronous replication configured, although sync rep is exactly the case where the serialized region is longest and the effect should be largest.
• The test table uses a bigserial primary key, whose sequence and index contention cap the control ceiling — in both arms, so it compresses the measured gap rather than inflating it.

None of this is publication-ready. The README lists what has to be fixed before any of these numbers should be quoted outside this repository. It is checked in so the measurements behind #83 are reproducible and auditable, defects included.

🤖 Generated with Claude Code

https://claude.ai/code/session_01M3RLizCyeXBBFJdBHGDvKW

Generated by Claude Code